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FACTORY-FLOOR COMMUNICATIONS IS 
FLIRTING WITH WHAT ONCE WERE PURELY 
OFFICE TECHNOLOGIES. ALTHOUGH WEB 
PROTOCOLS' MIGRATION FROM E-MAIL TO 
MUSCULAR MACHINERY ISNT TOTALLY 
PROBLEM-FREE, THE WEB'S ROMANCE 
WITH MANUFACTURING AUGURS WELL 
FOR A LONGER, HAPPIER RELATIONSHIP 
THAN MOST IN HIGH TECH. 




Web Technology: 

Sticking its nodes 
in everybody's business 



T 



he networking technology that underlies the World Wide 
Web is transforming not only the ways in which businesses mar- 
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ket and sell their wares but also the ways by which machines com- 
municate with each other. Whereas manufacturers of industrial con- 
trols have spent decades constructing a Tower of Babel — in the form 
of a welter of incompatible, proprietary networking protocols — the 



ubiquitous Ethernet and TCP are bid- 
ding to restore some sanity to industrial 
networks. 

Ethernet and associated protocols be- 
gan life with the idea that they would 
connect computers with peripherals and 
that companies would deploy those de- 
vices exclusively within benign and tidy 
office environments (see sidebar "A net- 
work-protocol primer"). Today, howev- 
er, such notions are history. The previ- 
ously prissy protocols are sticking their 
nodes into everybody's business. As a re- 



sult, the Web's networking technology is 
turning up with increasing regularity in 
the muscular machinery of the rust belt. 

In the days before 10- and 100-Mbps 
Ethernet (let-alone Gigabit Ethernet), it 
was common knowledge that Ethernet's 
physical-layer protocol, CSMA/CD, was 
unsuited to real-time applications. The 
protocol specifies that, before a node can 
transmit data, it must listen to the net- 
work and make sure that no other node 
is transmitting. 

Nodes that attempt to transmit simul- 
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taneously — that is, nodes whose outgo- 
ing messages collide — must wait for ran- 
domly generated intervals before trying 
again to send their messages. The idea is 
that, because each node independently 
determines how long to wait and choos- 
es its delay at random, the probability is 
small that, on the next attempt, the nodes' 
outgoing messages will again collide. 

The system works well, but it does not 
allow you to predict (except statistically) 
the latency of data. That is, you cannot 
predict how long a message must wait be- 
fore it reaches its destination. Moreover, 
if the message becomes corrupted during 
transmission, the receiving node detects 
errors and can request a retransmission, 
which can cause further unpredictable 
delays. A large amount of message traf- 
fic increases the likelihood of collisions, 
so on heavily loaded networks, retrans- 
mission can cause appreciable delays. 

In a real-time control system, unpre- 
dictable delays can be disastrous. Imag- 
ine the carnage if the valve that controls 
the flow of hydrofluoric acid into a tank 
doesn't close until after the tank is full, or 
if the motors that drive the pinch rollers 
in a mill that forms steel into a 20-ft-wide 
rolls don't slow down in synchronism! 

FAST ENOUGH FOR MANY PURPOSES 

Nevertheless, more and more control- 
system designers recognize that increas- 
ing network data rates have invalidated 
the bygone era's common knowledge. 
Ethernet is fast enough for many control 
systems — even in time-critical applica- 
tions. Ethernet networks that transmit 
kilohertz data in real time are rather 
common. Ethernet's suitability depends 
on the extent of the network, the traffic 
levels, the error rates, and how critical de- 
lays can be. The latency is unpredictable, 
but if no hard failures occur, data rarely 
fails to reach its destination. 

When analysis and measurements 
show that Ethernet can work acceptably, 
the logic of using it is often inescapable. 
Wiring is usually the largest part of the 
network's cost. If the wiring is already 
present, the network cost drops dramat- 
ically. With Ethernet, the wiring is usu- 
ally already present. Wherever you go to- 
day within the factories of US industry, 
an Ethernet network is rarely more than 
a few feet away. 

Of course, just because an existing net- 
work is close at hand doesn't automati- 
cally make it the right choice. For exam- 
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AT A GLANCE 

> Because of the dramatic network-speed 
increases that have taken place in the last 
decade, Ethernet despite its nondetermin- 
istic latency, is fast enough for many real- 
time control applications. 



> Standard Web protocols, such as 
TCP/IP, are less than ideal for real-time 
control and can lead to unacceptably slow 
network response. 



> A new breed of software, real-time pub- 
lish-subscribe middleware, can overcome 
the speed problems of the more familiar 
network-software protocols. 



> IC designers have cut the TCP stack's 
gate count to the point where the neces- 
sary hardware is just a tiny part of more 
complex ICs, thus enabling individual sen- 
sors to interface at almost no extra cost to 
networks based on Web technology. 



> It makes little sense for individual sen- 
sors to publish their own Web pages to 
company intranets. Reserve that job for 
higher level devices that aggregate the out- 
puts of multiple sensors. 



pie, if the network is already heavily 
loaded, the additional traffic that the new 
applications add can become the straw 
that breaks the camel's back. On the oth- 
er hand, Ethernet can be a good choice 
even if you must install a new network. 
Compared with other architectures, Eth- 
ernet hardware and support tools are rea- 
sonably priced and readily available, as 
is expertise in deploying and maintain- 
ing Ethernet networks. 

ELIMINATING THE SOFTWARE BOTTLENECK 

But although the Ethernet physical lay- 
er often works well enough to handle 
real-time control, the protocols that are 
common in Ethernet-based office appli- 
cations may not. When a networked ap- 
plication needs to be more responsive, a 
relatively new type of software, RTPS 
(real-time publish-subscribe) middle- 
ware can come to the rescue (Reference 
1). Middleware is a software layer that 
stands between your application and the 
operating system's networking facilities. 
Examples of such software are Real-time 
Innovations' NDDS and National In- 
struments' Data Socket. 



Under the publish-subscribe ap- 
proach, subscribing nodes specify the 
type of information they need and how 
often they require updates. Because the 
subscribers establish their information 
needs at the outset, this approach mini- 
mizes traffic associated with requests for 
information. In addition, the RTPS ap- 
proach can avoid wasting bandwidth on 
repeated transmissions of nonessential 
data that a subscriber fails to receive suc- 
cessfully. When a subscriber establishes 
how often it must receive data, it need not 
specify exactly which data points it must 
have. In such cases, if a data point fails to 
arrive, the next such point may suffice — 
as long as that point arrives within the 
subscriber's specified maximum time be- 
tween updates. 

Of course, some subscribers must re- 
ceive every message of a particular type. 
Moreover, the messages must arrive error 
free, and if they do not arrive in the or- 
der in which they were sent, the sub- 
scriber must be able to place them in that 
order. (An example of such message and 
subscriber types is a sequence of com- 
mands transmitted to a command pro- 
cessor.) The subscriber can specify these 
requirements at the outset. By time- 
stamping every transaction, the RTPS 
software enables subscribers to place 
messages in their intended order and to 
compensate for the unpredictability of 
delays. 

In a happy coincidence, Web technolo- 
gy enables designers of Web-based real- 
(continued on page 66) 

ACRONYMS 

CORBA: Common Object-Request- 
Broker Architecture 

CSMA/CD: earner-sense multiple access 

with collision detection 

DCOM: Distributed Component Object 

Model 

DNS: domain-name service 
HTML Hypertext Markup Language 
HTTP: Hypertext Transfer Protocol 
ICMP: Internet Control-Message 
Protocol 

IP: Internet Protocol 
MAC media-access control 
NDDS: network data-delivery service 
NFS: network-file system 
RTPS: real-time publish-subscribe 
TCP: Transmission-Control Protocol 
UDP: User Datagram Protocol 
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A NETWORK-PROTOCOL PRIMER 

By Stan Schneider, PhD, President, Real-Time Innovations Inc 



Everyone knows that the "stan- 
dard" Internet protocol is TCP/IP. 
However, many don't know that 
the network stack commonly 
called 'TCP/IP" also includes 
many other protocols, including 
IP, TCP, UDP, and ICMP. The 
entire stack runs on some hard- 
ware medium, such as Ethernet 
Ethernet is the most popular 
physical layer for high-speed 
networks. Ethernet sends infor- 
mation in approximately 1500- 
byte, individually routed 
"frames" to hardware MAC 
addresses. These addresses have 
a format such as 00:23:80:33: 
01 :44. They specify a hardware 
interface card and work only on 
one network. Ethernet frames 
are sent with no guarantee 



about the transmission, arrival, 
order, or much of anything else. 

IP underlies nearly everything 
on the wire (Figure A). IP is a 
simple protocol that exists most- 
ly to provide addressing (the 
ubiquitous "dot" addresses, such 
as 192.168.168.43). Routers use 
these addresses to send the 
information along the various 
hardware nets to the right desti- 
nation. IP packet lengths may be 
as great as 64 kbytes. The IP 
layer fragments the messages 
into underlying transport packets 
(for example, Ethernet frames) 
and then re-integrates them on 
the receiving side. IP transmis- 
sions are not guaranteed; they 
may arrive out of order or not at 
all. 



Figure A 
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ICMP ("ping," for example) is a simple protocol. UDP is a thin layer on 
top of IP that provides multiport addressing and a checksum. TCP is a 
more complex protocol that provides reliability and streaming data. 



ICMP is a simple protocol that 
sends control information 
between nodes. The best-known 
ICMP packets are "ping" mes- 
sages, sent to determine 
whether a remote node is alive. 
Other ICMP packets control 
routing, fault isolation, and con- 
gestion control. ICMP messages 
are sent inside IP packets. 

TO 3 also sends information 
inside IP packets. TCP provides a 
reliable, connection-oriented, 
streaming connection between 
two nodes. In other words, TCP 
breaks a stream of information 
into sizes that fit into IP packets, 
sends the packets to the other 
node, and then reassembles the 
packets into the same message 
that was sent If this article were 
sent over a TCP connection, 
every character would arrive at 
the destination in the order in 
which it was sent If an IP packet 
doesn't am've, TCP asks the 
sending node to resend the 
packet and then delivers the 
stream intact As a result the 
receiving application doesn't 
have to worry about losing data; 
it sees an uninterrupted virtual 
"data stream." 



remove control over delivery 
timing. That loss of timing con- 
trol can be a problem for real- 
time systems. 

UDP is a thin layer around IP. 
It provides connectionless "data- 
gram" packets with no guarantee 
of delivery. Using UDP is similar 
to mailing a letter. You don't 
really know whether it reaches 
the address you specified. UDP 
does, however, allow you to 
specify a receiving address, and 
it ensures that the information 
arrives uncorrupted if it arrives at 
• all. If this article were sent as a 
series of UDP packets, pieces of 
it might not arrive or might 
arrive out of order, but whatever 
did arrive would be correct 

UDP is every bit as much of a 
part of the standard TCP/IP stack 
as is TCP (Figure B). Many com- 
mon services are based on UDP, 
including the Windows NetBIOS 
system, the Unix NFS, and the 
DNS that resolves "www.rti.com" 
into an IP address. 

Because there are no connec- 
tions, UDP need not maintain a 
record of the state of the send- 
ing or receiving nodes. UDP can 
deliver the same packet to many 
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addresses either on a local net- 
UNDERLYING PROTOCOL or to multiple 

remote nodes (multicast). There- 
fore, UDP scales well to large 
one-to-many network communi- 
cations. Because it lets the appli- 
cation control retried transmis- 
sions, UDP is often superior to 
TCP for real-time data distribu- 
• tion. For high-performance com- 
munications, protocols such as 
RealAudio and RealVideo 



TCP obviously performs use- 
ful functions. It underlies most 
of the familiar higher level net- 
work protocols, such as HTTP 
(Web service), CORBA and 
DCOM. However, TCP's advan- 
tages come at a cost To provide 
a reliable connection, both 
nodes must maintain status 



Figure B 



information, such as what has 

been sent As in a telephone (www.real.com), and real-time 
network, if s difficult to maintain industrial middleware, such as 



i protocols are built on IP. UDP offers 
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many of these connections to 
other nodes at the same time 
Also, although the reliable pro- 
tocol is nice when you want 



NDDS, take advantage of this 
feature. It is obviously the job— 
and privilege— of these higher 
level protocols to control reliabil- 
ity and delivery timing. 
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time-control systems to model the systems 
and, before deployment, evaluate them 
more effectively than would otherwise be 
possible (see sidebar "Using the Web to 
make the most of mathematical models"). 
Several companies offer small Web 



servers that control-system designers can 
embed within higher level products. A 
company that offers an extensive array of 
hardware and software products, includ- 
ing specialized ICs and development tools, 
is NetSilicon. 



Meanwhile, a brand-new company, Ip- 
sil, has devised what it calls the smallest 
possible TCP/IP stack. Ipsil's initial prod- 
uct is small and inexpensive enough to 
make it a serious candidate for embed- 
ding within low-cost sensors and trans- 



USING THE WEB TO MAKE THE MOST OF MATHEMATICAL MODELS 



';'S 



At least two companies are in the 
business of helping engineers 
and scientists use the Internet to 
distribute and use mathematical 
lets and simulations. These 
lodels and simulations can rep- 
resent the behavior of any sys- 
tem or process in any discipline- 
mechanical, electrical, electronic 
chemical, biological, financial, 
and, no doubt others. Modeling 
of real-time control systems is a 
prime example. 

Historically, a large obstacle to 
the distribution of such models 
has been the developers' insis- 
tence on retaining control of 
their intellectual property. That 
I is, the developers insist on 
retaining control of the equa- 
tions and algorithms that under- 
lie the behavior of the model. 
Web technology offers a means 
of keeping models' proprietary 
parts locked behind a firewall 



yet allows users to input data 



and observe results. Web tech- 
nology also allows control of 
who can use the models and ' 

can enable intellectual-property tomers, MatLab Web Server soft- 
owners to charge for the use of ware is the best choice for dis- ] 



secure. For most model owners 
and users, C code is the most 
convenient form of output from 
the Compiler because it relieves 
the model user of the need to 
have MatLab to run the code. 
But C programmers can reverse- 
engineer the code— albeit not 
always completely. 

MatLab Run-time Server soft- 
ware is a somewhat more 
expensive approach that pro- 
vides greater security. The out- 
put of the Run-time Server is 
pseudo-code (P-code), which 
the model owner can distribute 
by the same means as those for 
C code. P-code is much less 
transparent, however. The Run- 
time Server can bundle an inter- 
preter with the P-code, enabling 
the code to run on machines on 
which MatLab is not installed. In 
many cases, though, execution is 
slower than that of the equiva- 
lent C program. 

THE MATLAB WEB SERVER 

For many MathWorks cus- 



Because spreadsheets, such as 
Excel, accept HTML tables as 
inputs, you can easily perform 

. further analysis on the model or 

. simulation output 

In one respect, however, the 
MatLab Web Server is at a disad- 
vantage with respect to the Mat- 
Lab Compiler and Run-time 
Server. Web Server models pro- 
duce static graphical output For 
example, if you want to see how 
a 3-D graph looks from a differ- 
ent viewpoint you can't rotate 
the picture as you can with 
graphics produced by code that 
the other two tools generate. 



pliers, or customers to be able 
to access certain models. In such 
cases, it can be appropriate to 
use a customized version of the 
Innovation Chain infrastructure 
to distribute the models from 
the owner's network 

Innovation Chain's approach 
allows intellectual-property own- 
ers to use their own executables 
. or to use any vendor's software 
to develop the models and sim- 
ulations. This agnostic approai 
to the underlying software is 
j possible because of the use of 
Excel spreadsheets as an inter- 
, face and control panel. The 



3 



Instead, you must specify a new interface sends user-supplied 



azimuth and elevation for the 
viewpoint and you can do that 
only if the model accepts those 
parameters as input 



INNOVATION CHAIN 



their property. 

Users of MatLab and other 
scientific and technical comput- 
ing tools from The MathWorks 
. can distribute models in several 
ways, one of which, the MatLab 
Web Server, depends strongly 



tributing models. The Web 
Server approach is not only eco- 
nomical, but also provides the 
greatest security because the 
code need never leave the intel- 
lectual-property owner's server 
j* hardware. Moreover, the Web 



on Web technology. Server supports not just MatLab 

Of The MathWorks' approach- but also The MathWorks' 

es, the most straightforward and Simulink product whose stock in 

one of the least costly uses the trade is, as its name implies, 

MatLab Compiler. With the Com- simulation. 



piler, a model's owner can dis- 
tribute compiled MatLab code 
by any conventional means, 
such as mailing disks, attaching 
files to email, or providing 
downloads. Unfortunately, this 
approach is not particularly 



When you use the MatLab 
Web Server to distribute a 
model, you create an HTML 
interface through which users 
| supply data to the model. The 
model's output is HTML as 1 
well-often HTML tabli 



data to the remote models, 
launches them, and returns the 
simulation results when execu- 
tion is complete but doesn't 
allow users to access the 
model's underlying algorithms. A 
Start-up Innovation Chain's proprietary plug-in enables Excel . 
business is complementary to to communicate with the remote 
The MathWorks' model-distribu- server and to handle complex 
tion activities, innovation Chain 
focuses on the infrastructure for 
Web-based model and simula- 
tion distribution rather than on 
the applications that generate or 
run the models. For example, if 
the intellectual-property owner 
prefers to provide free access to 
J Hs models, Innovation Chain can 
provide its infrastructure tools to 
enable such access. Publishers 
of periodicals such as NASA 
Tech Briefs distribute models via 
Innovation Chain's servers and 
promote those models through 
articles in the publication. Users 
■~?ss the models via links from 

publisher's Web site (for 
NASA Tech briefs, the URL is 
,.www.innovationchain.conVfirsta 
i?CN=lll). 

Some property ownere may 
only their employees, sup- 



data types, such as meshes and 
fields. The free plug-in is avail- 
able for downloading from Inno- 
vation Chain's Web site. 

Additional features of Innova- 
tion Chain's approach include . 
providing different classes of 
' users with different levels of 
'^access to models. For example, 
■ site administrators might permit 
' only those users who contract 



for a high level of access to 



1 



solve problems. Other users 
might be referred instead to 
' prepackaged "bestfliatch" solu- 
tions of similar problems. Fur- 
; thermore, Innovation Chain's 
.'tools can provide intellectual- \ 
property owners with feedback 
on the popularity of various I 
..aspects of each model or simu-^ 
lation. 
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ducers. The product is an IC that con- 
tains the stack, a u.P core, I/O ports, a 
low-speed network port, and both RAM 
and ROM. The device, which contains 
approximately 5000 gates in an eight-pin 
surface-mount package, will cost less 
than $1 in production quantities. 

Ipsil also plans to offer the product as 
a standard cell that designers of higher 
level products can integrate into more 
complex ICs. For such designers, Ipsil of- 
fers a $ 1 00 development kit that includes 
the IC as well as development notes and 
application examples. A version of the IC 
that incorporates a lOBaseT Ethernet in- 
terface would contain only about 20,000 
gates. 

Nevertheless, you shouldn't get the 
idea that Ipsil wants to see thousands of 
sensors in a manufacturing plant all 
publishing their own Web pages to the 
company intranet. Box-level products, 
such as Capital Equipment's WebDaq, a 
data-acquisition system, publish Web 
pages that contain data acquired from 
multiple sensors. This approach elimi- 
nates the need for specialized client soft- 
ware. All you need to view a WebDaq 



page is a networked computer equipped 
with a standard Web browser. 

TRILLIONS OF DEVICES 

Although it has nothing against this 
approach, Ipsil has its eye on lower lev- 
el products that sensor manufacturers 
produce by the thousands and manu- 
facturers of information appliances may 
produce by the millions. Indeed, Ipsil be- 
lieves that the total market for its mini- 
malist technology could amount to tril- 
lions of units. Vendors of box-level 
data-acquisition products often sell sin- 
gle units and only occasionally take in- 
dividual orders for quantities of more 
than 100 units. 

Ipsil's view is that publishing the data 
to an intranet should be the responsibil- 
ity of a higher level server that aggregates 
the data from many sensors. Efficient use 
of network resources is paramount in 
such architectures, so despite their com- 
pactness, simplicity, and low cost, Ipsil's 
devices can incorporate RTPS middle- 
ware as an embedded feature. 

Indeed, embedding such a software 
layer within devices such as sensors 



makes enormous sense. Even though 
networks have taken tremendous strides 
over the last decade in increasing speed 
and reducing cost, interconnection is 
still the most significant part of sensor- 
based systems' installed cost. The cost of 
functions that silicon chips can incor- 
porate has declined much faster than the 
cost of wired — or 
wireless — intercon- 
nects. Using sensors 
that employ embed- 
ded intelligence to 
limit the amount of 
transmitted data is far 
more cost-effective 
than increasing the 
network bandwidth, 
collecting more data, 
and trying to deter- 
mine what to make of the data as it 
fills — and then overflows from — mas- 
sive networked storage devices.D 
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